home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 2173 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.3 KB  |  109 lines

  1. Newsgroups: comp.sys.amiga.misc
  2. Path: EU.net!sun4nl!hguijt
  3. From: hguijt@inter.NL.net (Hans Guijt)
  4. Subject: Re: OS features
  5. Message-ID: <DLE6q5.71B@inter.NL.net>
  6. Organization: NLnet
  7. X-Newsreader: TIN [version 1.2 PL2]
  8. Date: Thu, 18 Jan 1996 19:42:05 GMT
  9.  
  10.  
  11. (sorry for a chaotic posting - I added to it on 4 occasions and this didn't
  12. help textflow)
  13.  
  14. Michael van Elst (mlelstv@serpens.rhein.de) wrote:
  15. >>What other functions do you mean here? Keep in mind that not everybody is
  16. >in
  17. >>the business of writing 'normal' programs. Some people need more, and so
  18. >far
  19. >>I think the Amiga catered well to them.
  20. >
  21. >Oh.. Things like SuperState() or SetIntVector().
  22.  
  23. I agree, to a point. The real functionality of SetIntVector () is not 'put
  24. the machine into supervisor mode', rather it is 'react quickly to some
  25. hardware event you think you can handle better then the OS'. This
  26. functionality is necessary for some hardware drivers (anything that uses
  27. int7 for instance).
  28.  
  29. And I don't see a use for SuperState, but that just means I cannot foresee
  30. all possible future uses for the Amiga.
  31.  
  32. Does PPC have user/supervisor modes anyway?
  33.  
  34. The point I wanted to make was that neither you nor I can foresee where the
  35. Amiga will be used, nor should we try to limit it to our vision. If the NASA
  36. wants to use the Amiga in a future spaceship but can only do so if the Amiga
  37. can process interrupts in a certain way I don't want them to turn to clones
  38. because DOS allows the ultimate flexibility of not having an OS to worry
  39. about.
  40.  
  41. >And don't get me wrong. I don't want to remove these calls, but I want
  42. >to assure that most programs do not use them. What is good in memory
  43. >protection when you can easily circumvent it.
  44.  
  45. How could you assure most programs do not use certain calls?
  46.  
  47. The question is: how much security do you want?
  48.  
  49. - Do you want full security (ie. OS *always* running)? This will make it
  50. hard to run other OS's on the Amiga. It will also stop demo's and games from
  51. taking over the machine completely.
  52.  
  53. If this route is taken there should be libraries for manipulating hardware
  54. such as the copper more directly.
  55.  
  56. - Or do you want programs that can crash if they take trouble to do it? I
  57. would be happy with this, after all I could always kill those programs if
  58. they bothered me too much. I am far more concerned with the accidental
  59. crashes we have now.
  60.  
  61. The only way you can get 'them' (you know, the K0derz) to use the OS is to
  62. built the basic a1200 in 4-5 flavors, each with different hardware. *And*
  63. change that hardware at regular intervals.
  64.  
  65. >>An 68000 emulator could run without memory protection, and new programs
  66. >>should use the MEMF_PUBLIC flag which indicates memory is to be shared
  67. >>between applications. I don't see any problem here.
  68. >
  69. >Why would you want to run 68000 programs unprotected and why do you
  70. >want to keep separated APIs for 68000 and PowerPC ?
  71.  
  72. I don't actually *want* to run 680x0 programs unprotected, but adding
  73. protection to the 680x0 part of the future amiga's seems far more trouble
  74. than it's worth. The way I see it those machines will either get new
  75. software (which is protected, and which will replace old software in a short
  76. period of time) or it will *not* get new software (and die, thereby solving
  77. the problem the 'other' way).
  78.  
  79. Adding protection to PPC programs is a lot easier done, because none exist
  80. yet that can break programming conventions.
  81.  
  82. As for the separate API's, there will have to be a layer of stubs anyway for
  83. 680x0 code inside the emulation, it could just as easily compensate for any
  84. differences between the old and new API's.
  85.  
  86. Reading back I see I also implied that PPC programs would be unprotected
  87. from 680x0 programs. What I really meant was 'PPC programs should always be
  88. protected, 680x0 programs should be allowed to crash each other just like in
  89. the good old days'.
  90.  
  91. >And no, MEMF_PUBLIC is probably not a good method and definitely not
  92. >the best.
  93.  
  94. It was really a placeholder for 'some way I cannot be bothered to specify or
  95. even think about to tell the system this memory will be referenced by
  96. multiple tasks, and is therefore not subject to the full extend of memory
  97. protection techniques as currently employed by the operating system'. It
  98. wasn't really meant as a solution although I suppose it could be one.
  99.  
  100. A better solution would probably take into account that a message has only
  101. one owner at a time (either the sender is working with it or the receiver -
  102. never both).
  103.  
  104.  
  105. Bye,
  106.  
  107. Hans
  108.  
  109.